Linux kernel workshop at NIT, Raipur

I travelled to Raipur, Chhattisgarh on the evening of 20th January, 2017 to conduct a “Linux kernel workshop” at NIT, Raipur. It was my first time travelling to Chhattisgarh. Lalit [student of the university and program co-ordinator] reached out to me sometime during October, 2016 for having a talk on Linux kernel at their university as part of Codeutsava 1.0. Based on my previous experience of conducting kernel workshop(s), I told them to have a full day session so that I can have enough time to solve the queries of participants.

Usually for the kernel first patch workshop I followed a structure of having 1st session as a talk Linux kernel and related things. And then in the other session I go through the process of creating first patch along with the participants. But the issue with the structure was that participants have to build and install latest kernel by themselves as compiling kernel takes lot of time. This usually turns out too much to be a prerequisite as most of university students do not use Linux in their day to day life. So, this time I decided to include the building and installing part in the workshop itself and planned it as a full-day session. The idea was to have morning session as a talk and meanwhile helping participants with the issues to setup things. And then practical afternoon session where I along with participants can go for creating and sending first patch in the LKML.

Although planning can always help, there are certain things which are out of your hands. On my way to University from the airport, students told me that they will not have internet next day because of some issues from the local service provider. Thankfully I had evening flight on Sunday, so we decided to have first session during the Saturday afternoon and practical session on Sunday morning. For the Saturday morning, we decided to go for an interactive session with the Girls. Anyway interacting with the Girl students’ is my favorite part whenever I visit any university for taking sessions. This helps me to understand their perspective [and correct some of wrong myths associated with that] about computer science, technology, open source and STEM in general.

So, Saturday began with an interactive session with the Girls. I talked about Outreachy and my journey of becoming a Linux kernel engineer. Initially they were bit hesitant but slowly they opened up I guess. Most of them didn’t know anything about Outreachy and GSoC. So, it was good to have such session there, specifically when application of the Outreachy will be open very soon.

After the lunch, I started a session with giving a talk on ‘Introduction to Linux kernel hacking’. I started the session with introducing the fun world of open source, some common practices, introduction to tools like Git and ways of contributing to the open source projects. After that I wanted them to play a bit with Git and explore the kernel code with that. But it turned out that most of them didn’t have kernel source code and some of them were running Windows [Although Linux, Linux kernel source and Git were pre-requisites]. Eventually organizers announced that on facebook event and not all participants checked that. But anyway I already told them to have few USB keys in case some of them don’t have source code. So, eventually we were good to go after some initial issues. Like any university[1], here also students had only definition of the Linux kernel in their text books. So, it was fun to talk about what is Linux kernel, what part it plays in the OS, why it is important etc. I also talked about the Linux kernel development process[2] and how it works. Next day we had first patch session which went well too. I was happy that they had questions for me. [And I hope my answers helped them to understand the things]. Slides and other material of the workshop can be found here.

img_20170202_230107

I also spent some time with girls of the university on Saturday evening and had share of my fun by connecting with them. Overall, I think I really got a lot out of this experience, and I hope students gained something from my experience & perspectives as well. Huge thanks to the organizers and volunteers for organising the workshop, and being a good host. Also, thanks to everyone who participated in the workshop and hope to see more traffic in the LKML!

[1] I really hope that universities will offer course on Linux kernel or kernel in general some day. As far as I know, only one Indian university[IIT Bombay] offers such course. Check it out here if you are interested. I think they have good list of assignments and projects.

[2] I recently saw good talk by Greg on the same. This is informative for newbies.

 

Process of creating first patch

So this blog pretty much covers everything about the process and commands which I follow for the practical session of my Linux kernel first patch workshop.

I usually prefer to go for the simple syntax errors [suggested by checkpatch.pl] for the first patch practice. Also, usually it’s a good idea to send clean up patches for the files in staging directory only. Specifically when you are newbie and sending a patch in a kernel for the 1st time.

Note that this is just a list of commands, for more detailed versions and things I explained, you can refer to the slides and first patch tutorial. Also, make sure to run all of these commands under the source code directory of the Linux kernel and where Makefile resides. Do not run these commands under specific directories.

Step 1:

Run checkpatch.pl over the directory of your choice under the staging to edit a file.

perl scripts/checkpatch.pl -f drivers/staging/media/bcm2048/* | less

Step 2:

Check the code. Use following command to see who did that change and why. This is
useful in a practice to understand the approach of a code author.

git blame -L x,y file_path.c // x,y specifies the Line numbers

e.x  git blame -L 30,32 filr_path.c 

This will give you a list of commits. You can use ‘git show <commit id>’ to check the
whole commit.

Step 3:

Once done with changing the code, compile the file. It should produce the .o file without any errors.

make file_path.o

Sometimes you may want to run ‘make file_path/’. For example, you can run ‘make drivers/staging/media/bcm2048/’ .

Step 4:

If the file successfully compiles then go for creating a patch. For that, first
add your changes in a git.

Git add <file_path>

Step 5:

Now, create a commit.

Git commit -s -v

-s adds signed off by line and -v adds git diff in the commit you are creating.
You can read about the patch philosophy over here. For the patch best practices, refer to patch philosophy.

Step 6:

Create a patch now.

Git format-patch -o /tmp/ HEAD^

This will give you temporary .patch file. ex.

Step 7:

In the LKML, we prefer that new patches should not introduce any syntax warnings.
So, run checkpatch.pl over your temp .patch file. And solve sytax errors if there
are any.

scripts/checkpatch.pl <.patch file>

Step 8:

Get the list of maintainers and mailing lists to send that patch.

git show HEAD | perl scripts/get_maintainer.pl –separator , –nokeywords –nogit –nogit-fallback –norolestats –nol

Step 9:

Send the patch using git send-email.

git send-email –to= –cc= <.patch file>

To setup git send-email you can go for this blog post.

Also, few other commands which I use while giving first patch workshops are here:

To check the modified file:

git status and git diff

To check the commit after creating it.

git log

I’ll write separate posts explaining what to do when going for the v2 of the
patch.

Sending patches with git send-email

In this post I’m explaining how to send Linux kernel patches with git send-email using your gmail account. This is also useful for my Linux kernel workshops and generally for kernelnewbies as well. So, here we go:

First, you need to tell git what your name and email address is, so that it can be used in the authorship information in the git commit. Create a file called .gitconfig and add lines like these to it:

[user]
           name = Vaishali Thakkar
           email = vthakkar1994@gmail.com

Make sure that the email you specify here is the same email you used to set up sending mail.

The next step is to indicate to git-send-email which SMTP server it will use to send your patches and to specify its parameters e.g. encryption protocol, port etc. So, for gmail accounts add following lines in .gitconfig:

[sendemail]
           smtpuser = vthakkar1994@gmail.com
           smtpserver = smtp.googlemail.com
           smtpencryption = tls
           smtpserverport = 587

So, your final .gitconfig file should look something like this:

[user]
           name = Vaishali Thakkar
           email = vthakkar1994@gmail.com
[sendemail]
           smtpuser = vthakkar1994@gmail.com
           smtpserver = smtp.googlemail.com
           smtpencryption = tls
           smtpserverport = 587

There are many other options which you can add for the same. Those can be find here. But with above setting at least you should be able to send the patches. You can setup the password in the config file itself with ‘smtppass’ , if you don’t want git to send ask your password every time while sending patches.

After this, try sending a .patch file to yourself by using following command. If that doesn’t work then check if you have some typo in .gitconfig.

git send-email –to file.patch

Also, for the new ubuntu distros send-email might not work. This is because Linux distributions often like to split up packages to avoid dependencies needed only by optional functionality (like send-email). So, in that case you can install it with the following command in ubuntu:

sudo apt-get install git-email

Also, if you have If you have multi-factor authentication setup on your gmail account, you will need to generate an app-specific password for use with git send-email. Visit this site to setup an app-specific password. Usually allowing less secure apps works as well.

Once, git send-email is working properly, you can just go for sending patches to the list of maintainers and mailing lists after running scripts/get_maintainer.pl over a patch.

Wrapping up 2016 and few 2017 goals

Last year I set myself some goals and was able to achieve most of them. Also, in terms of  amazing things I learned this year, some wasn’t actually part of my last year goals. But this post is a part reflection and part announcement of my year 2017 goals.

  • I completed one year in the Bengaluru. I learnt cooking and about many other responsibilities which comes with that ‘exciting living alone life’. This might seem ridiculously low – but we all start somewhere I guess. I never lived alone before this.
  •  One of the amazing thing that happened to me in 2016 was I was able to overcome on my fear of public speaking. So far I gave 6 talks. Attended many tech related events and meetups. We started Bangalore kernel meetup and so far we had 3 meetups and 1 full day hackathon. I am really happy to see so many people interested in the Linux Kernel. Hopefully, we will have more meetups in the next year.
    • 2 of them were at Bangalore kernel meetup
    • 2 of them were at Indian universities
    • 1 was at LinuxCon Japan
    • 1 was at LinuxCon Europe
  • Details about my talks can be found on my website [under talks section]. Unfortunetly, I couldn’t attend few other conferences like SeaGl, CodeMotion, DevConf Cz etc despite being invited as a speaker because of one or other reasons. Hoping to attend them in the future.
  •  Travelled in 3 countries and 4 different states of India in last year.
  •  Mentored in GSoC 2016.
  •  Did try to go for some adventurous activities. Ended up having some amazing  experiences except the one which gave me a fourth fracture of my life. [But never  mind that, I’ll continue doing the same in 2017 :P]
  •  Started learning Kannada but lost the track somewhere.
  • Met many amazing people in person. But someone who deserves a special mention is Julia Lawall. It was exciting to meet her in person after knowing her since last 2 years. I even spent 2 days at her place in Paris. [This trip may deserves a separate blog but let’s keep it to myself for some more time. :)]
  •  Started reading books again. I was always interested in literature but somehow lost the track after my 12th grade because of many other university and undergrad life related things. 🙂

Goals 2017:

  • Planning to go for giving more technical talks. Someone advised me that I should try to give inspirational talk at some point, but I am not sure about that at the moment. So, for the next year I want to focus on giving technical talks [mostly Linux Kernel and open source related]. I may want to try some other topics [e.g Diversity, women in tech etc] after mid 2017 but not before that.
  • Last year I gave 2 talks at Indian universities. I usually receive so many mails from students regarding their doubts with contributing to the Linux Kernel. And most of them have same questions and issues. I have tried to answer some of them on Quora and I always try give replies to those mails. But I still feel that practical workshop gives good and quick results. So, I am planning to take more ‘Linux kernel hacking workshops’ at universities Indian universities. This workshops will be on weekends but I am limiting them to only one in a month. You may want to check this form if you are a student and want to invite me for conducting a workshop at your university.
  •  I am planning to read 2 books each month this year. I have my amazon wishlist over here. Feel free to give me more suggestions about the same.
  • I want to go for a 7-10 days trekking trip. I have few places in my mind but suggestions for the same are always welcome. [I am planning to take it sometime during mid 2017]
  • Planning to start a regional chapter[Bangalore] of LinuxChix India. Will share the more details about the same in future.
  • I have few other goals for myself but would like to keep them to myself at the moment. May be I’ll share those stories in the future. 🙂

Thanks for reading and I hope everyone will have an amazing year ahead!

[Outreachy] Tips for the kernel newbies

Next round of Outreachy has started from September 12, 2016. I usually get lot of mails and messages through social networking sites regarding Outreachy and generally for the contribution to Linux Kernel. I worked as an Outreachy intern in Round 10 and last summer I also worked as a GSoC mentor under the Linux Foundation. GSoC project I mentored was also related to Linux Kernel. So, I guess it is probably right time to give few tips to prospective applicants of the next Outreachy round. Some of these tips also applies to every newbie who wants to contribute to Linux Kernel.

General tips:

  • Start early so that you have enough time to understand how community works in general and to decide which projects you are interested in.
  • Do not hesitate to ask questions. But keep in mind that mentors also expect you to do some sort of search before asking a question. So, it is important to understand  what questions to ask. The paper How To Ask Questions The Smart Way by Eric  Raymond and Rick Moen is an excellent guide.
  • Take mentors’/reviewers’/maintainers’ comments positively. And work on them to avoid repeating same mistakes again. Also, learn from others’ mistakes. I am still used to read comments of developers on others’ patches so that I don’t repeat the same mistake in my patch. I followed the same rule during my application round as well. So, read comments of mentors on other applicants’ patches and try to follow them as well.
  • If something is not clear in the comment then please ask. It is better to ask at that time than repeating the same mistake again. This will save your time.
  • Be nice and respect others’ point of views. Definitely we like to discuss on technical parts but arguing politely will help you to create bonding and it is necessary for the healthy community as well.
  • The culture in a particular open source community may vary from that in other communities. Kernel community is famous for their frank opinions. Generally the comments on your patch is for your code or the change you are proposing, and not for the person as an individual. So,never take those comments personally. Take them positively and try to improve the quality of code for the next contribution.
  • Engage in community. We like when applicants helps each other. Never look at this as a competition. In the end, we all are going to learn something. This is true for both mentors and applicants.

Kernel contribution or patch related tips:

  • First kernel patch tutorial is your friend. This includes everything from installing things to sending your patches properly. Read it very carefully.
  • Usually in Outreachy we advise applicants to start from checkpatch.pl issues just to give  them an idea about how community works and to help them get started with contributing to the Linux Kernel. But not every checkpatch.pl warning/error is right. So please try to understand why that warning is there instead of fixing them blindly. There are false positives as well.
  • Do not top post while responding to mails. Look at the details of how to respond to mails inline.
  • Do not copy commit log and subject. You can check the other patches for the reference but copy pasting will never help.
  • For the subject line always run ‘git log’ to check what kind of subject lines are used for the particular file.
  • Quantity of patches matters but quality of patches is important as well. Move from checkpatch.pl issues once you get the idea of how things are working. This will help you to learn more.
  • Usually in the Linux kernel projects, we have small tasks for the applicants by mentors. Work on them and ask questions to mentors if something is not clear.
  • Be consistent in sending patches. Being in touch with the mentors help them to understand your perspective for the project.
  • Two important things to do before sending every patch:
    1. Always compile-test your patch before sending it to the maintainers/mailing lists.
    2. Always run checkpatch.pl on your patch.

    Half of the time this will show you if your change is correct or not.

Application related tips:

  • Never lie about your commitments for the internship period. Be clear and discuss this with mentors of the project you are applying.
  • Mention about what kind of work you have done and how this will help you achieve your goal in the project. The point of mentioning this tip here is, you can have idea about what kind of patches you should send during the application period.

Last but not least, always remember that we all were newbie at one point of time. So, never feel embarrassed or bad when something is not working. You are amazing and we are thankful to you as you are helping us to improve our community or code or even ourselves as well.

Welcome to the kernel community and all the best everyone!

LinuxCon Japan, 2016

A few weeks ago,  I had the pleasure of flying to Tokyo, Japan to participate in LinuxCon Japan, 2016. It was my first visit to Japan.

IMG_20160714_065810                                           Morning view from the 18th floor of the hotel 

The conference was held at Hotel Chinzan-so, Tokyo from 13th to 15th July, 2016.
My tutorial on Coccinelle was scheduled on 15th July. Slides of all talks can be
found here and photos of the event can be found here. It is technically impossible
to write about all of the talks I attended but I would just like to give a summary
of few talks which I liked or was something I was really interested in.

Keynotes highlights:

There were amazing keynotes from industry leaders on all 3 days including a talk
with Linus Torvalds and famous kernel developer panel. I am not going to cover
all of them but few which I liked were Jonathan’s kernel report. One of the
interesting thing he mentioned was about security vulnerabilities. The point
was about eliminating the classes of such vulnerabilities in the kernel. The
keynote session of Dirk Hohndel in conversation with the Linus Torvalds. It was
interesting that at some point they talked about the persistent memory as well.

On the third day there was famous kernel developer panel moderated by
Greg Kroah-Hartman and chaired by James Morris, Laurent Pinchart, Christoph
Hellwig, Masami Hiramatsu. Many questions from the audience were really good. Most
of them were from newbies about how to get started with the kernel and what after
sending clean-up patches. The panel also talked about the Outreachy [the program I
participated in] and how it is helping people to get involve with the community[1].
They also discussed about the people who found a job in the same area after the
internship. James also talked about me and my talk over there. Oh, did I mention
James Morris is my manager!

IMG_20160715_124254                                                                SUSE Robot at the booth

My talk:

I gave a tutorial on Coccinelle. My tutorial was scheduled on 3rd day of the
conference. I like to give talk before the lunch. So, it was perfectly
scheduled I would say. As that was the tutorial, I included exercises in the
talk. People who never heard about the tool seemed to be happy with the
results of the exercises. I had few discussions after the talk regarding expanding
the work of Coccinelle.

1talk                                           Me giving a talk, courtesy: Linux Foundation events

Slides of my talk and solutions of the exercises can be found here.

Other talks:

James Morris talked about the current state of the Linux kernel security subsystem.
He also talked about the kernel self protection project[2] along with other things.

Check the slides here:

Click to access linux_kernel_security_linuxconjp2016.pdf

One of the another interesting talk was on refectoring kernel strings for saving the
memory by Wolfram sang. Coccinelle has been very useful in finding the functions like
this. Wolfram himself is using Coccinelle scripts for this. I had good discussion
with Wolfram on this later on. One of the intersting thing in the talk was on slide
at slide 18. [Not going to reveal the secret, just try to take the quiz by your
own :P]

Check the slides here:

Click to access LCJ16-Refactor_Strings-WSang_0.pdf

One of the another talk was on successfully porting KASan to a bare metal
hypervisor by Alexander Popov was useful in understanding what issues he faced
while doing that. I personally love KASan because of the use-after-free bugs
reported by it in the Linux kernel. Had some discussion with Alexander after my
talk.

Check the slides here:

Click to access Alexander_Popov-KASan_in_a_Bare-Metal_Hypervisor_0.pdf

Few other which I liked were Address Range Memory mirroring by Taku Izumi and
How Google uses and contributes to open source by Marc Merlin. I attended few
talks on containers as well.

Concluding Note:

LinuxCon Japan was an amazing conference. The best part was of meeting many awesome people of the Linux kernel community after working with them for about 1.5 year. Thanks to Linux Foundation for organizing such a nice event and looking forward to attending many other Linux foundation events. Also, thanks to my employer for taking care of all the expenses.

Special thanks to Anjali rajith who showed me the city next day as I had flight in the
afternoon.

[1] Laura Abbott wrote very useful article on this, providing various ways to get involved with the kernel community. Check this out if you are also looking for ways to get started in contributing to the Linux kernel.

 

Yes, It’s my glass of juice!

Hello people!

I am back with some more interesting stories of my journey with the Linux kernel and open source. I have like dozen drafts saved in my google doc for the blog posts but none of them find their place to be published here for one or other reason.

Actually since I have relocated to the Bangalore, I am busy with the work on weekdays and in attending/speaking at events on weekends. It’s almost 6 months since I joined Oracle as a Linux kernel engineer and the journey so far has been fantastic. But I am not going to write about that in this blog [may be some other day!]. This time, I would like to share about my experience at speaking local/national events/conferences. So far, here is a list where I spoke at in last 5 months.

1. Took a session on ‘Contributing to Linux kernel’ at first Bangalore kernel meetup [slides, blog]
2. Conducted a workshop on ‘Contributing to Linux kernel‘  and took a session on ‘Getting started with contributing to open source‘ with Tapasweni Pathak at NIT, Calicut in FOSSMeet, 2016 [slides]
3. Took a session on ‘Getting started with contributing to open source’ at NIE, Mysore [slides]

With this I also had some casual webinars with some university students whenever it was not possible for me to present a talk in person. After all of this, I thought it’s good to write answers of 2 W’s. Why and What! So, let me write an answer of them.

1. Why I decided to speak at  events/conferences?

To get out of my comfort zone :

Yes, I thought to start speaking at conferences because I wanted to get out of my comfort zone. During my early college days, I was someone who could’t even raise a hand during lectures to ask the questions because I was used to think that I am supposed to know all of the answers. I think this feeling is common with many people. But Open source and Outreachy taught me that no question is a silly question and it’s good to speak up when you have valid points. Although that was all limited to mailing lists or IRC discussions. So, my primary motive was to to kill my fear of public speaking.

To share and improve my knowledge:

I think it’s a false assumption that when you are speaking at the event, you are just sharing your knowledge. Actually it’s more about improving your knowledge than sharing it. When you decide to give a public talk, you need to be ready for each and every question that can come in to mind of audience while attending your session. And sometimes you need to be prepare for out of context questions as well [Someone asked me about Iphone and Nexus 6P at one of my talk :D]. Actually this improves your knowledge about things and how you look at things. Also, the talks I have given till now had more percentage of students [2 university talks]. And they had lots of questions about which I didn’t even give a thought before that. So, this actually helped me to become more accurate about things and information while talking about them or including them in my talks.

– To be more socially active:

I am an introvert and I found it difficult to start conversation with strangers [I still do]. But I realized that speaking at public events/conferences can help to become more socially active. Because you are the one from whom people are expecting the answers of their questions and wants to discuss about your talk or things in general. On top of that, best part is you don’t need to worry about saying ‘Hi’ first. 🙂

– Giving back to the community:

During my open source journey, people have helped me a lot in many ways. And by giving public talks I wanted to give my few cents to an amazing open source community. And I am counting this as a success at some point because we have got contributions from the students/individuals in the Linux kernel after that.

2. What I learnt from speaking at these events/ conferences?

– It’s ok to be nervous:

Yes, it is pretty natural to be nervous but the important part is how you are going to handle that nervousness. One of the thought which helps me in handling this is ‘I have something to say and I am there because I want people to hear that’. And you know what, this actually helps me in communicating my ideas to the audience very clearly with the confidence.

– Became more confident by travelling alone:

I did my schooling and graduation from my hometown only. So, travelling alone never happened to me before relocating to Bangalore. But I was always sure that I can handle the things by my own [although my parents were not :D]. So, actually after this my parents have become more confident about myself than me.

– Learnt to talk with strangers

Either it’s about talking with the co-passengers or organizers of the events or attendees, I learnt how to talk with strangers. And that actually led me to some interesting conversations. For example, at NIE I was free after the talk, so I went to roam around the city with some girl students. And we actually had some nice discussions about how they can encourage more girls to participate in coding and which kind of sessions they can conduct at their universities. I got to know about different perspectives of the girls at university level.

So, yes the important thing I realized after speaking at these events is ‘It’s my glass of juice’ and if I can do this then anyone can I guess. Now I am hoping to speak at some international conferences in upcoming months [I was previously invited at LinuxCon Europe, 2015 and Devconf cz, 2016 but couldn’t make it due to some reasons.]. I am also open for giving talks at Indian universities as well. Because I believe students are the future developers and there are universities where students does not even have any idea about open source and how open source projects works. I have also seen cases where students have never used Linux during their 4 years of undergraduation [yes, not even once]. And I am hoping to change this scenario in India.

Finally, thanks to Outreachy and organizers for sponsoring the trips. And with this, I am signing off for now. Ping me if you have any questions about my slides or talks or open source/Linux kernel.

Thanks for passing by.

P.S. The only reason behind the title of this blog post is, I don’t like tea/coffee. 😀

 

Wrapping up year 2015 and plans for the new year, 2016

It has been around 4 months and I haven’t had written a single blog! I missed blogging. I wanted to share many things through this blog but for one or other reason didn’t get a time for that. So, finally I decided to write this post. This is going to be non-technical blog, I’ll write about my learning at Oracle in separate posts.

The year 2015 turned out to be one of the awesome year of my life. I went through lot of ups and down which almost changed my life. So, here are some highlights from the year 2015 in no particular order:

  • Got accepted as an Outreachy Linux Kernel intern and worked with my mentor Julia lawall on project Coccinelle
  • Became active contributor of Linux Kernel community and got a chance to interact with so many intelligent people in open source community
  • Finally done with my graduation in computer engineering
  • Selected as a winner of Linux Foundation Training scholarship, 2015 under the Kernel Guru category
  • Became physically fit [Oh, breaking 2-3 fracture bolts are an exception :P]
  • Got a chance to attend LinuxCon, Europe with other Outreachy interns but Indian interns couldn’t make it because of visa issues. Hope to attend it by this year.
  • Helped Outreachy round 11 applicants for Linux Kernel specific tasks during application period
  • Joined Oracle in November as a Linux Kernel Engineer and started living a life I always dreamed about
  • Relocated to Silicon valley of India – Bangalore
  • Mentoring for RTEMS project in Google Code In to help pre-university students with open source tasks
  • Interviewed by one of the well known open source journalist Swapnil Bhartiya for the IT World magazine. Here, is a link of my interview.
  • Started writing on Quora in my free time and wish to continue it in a next year as well
  • Finally received my new Lenovo ultrabook t450 yesterday [after so much wait] and just done with setting up things in it. Perfect end of the year 2015, isn’t it! 🙂

Some of my future plans:

  • Excited about new adventures in a new city
  • Hoping to learn so many new things by contributing more in the Linux Kernel community through my new job
  • I wish to complete some of my personal projects this year
  • Planning to contribute in other open source projects of my interest this year
  • We have started new Linux Kernel meetup group in Bangalore and I am very much excited for the first meetup which is on 16th Jan, 2016
  • Started learning Kannada and wish to continue it in this year so that I can connect with local people in a more general way
  • Planning to attend some conferences and meetups

There are some more updates and plans but let’s just wait for the right time to publish them.

Basically there are so many expectations from the up coming year and I hope to learn more from new experiences. I will try to write a blog more often.

Stay tuned and have a great year ahead!

Devm functions and their CORRECT usage

Hi,

Lets start this blog with some good news. Guess what, I won the Linux Foundation Training Scholarship under Kernel Guru category. I am so excited for taking Linux Foundation training class. They announced names of scholarship winners in LinuxCon NA which was in settle last week and it came out that I am a youngest scholar who won this scholarship. 🙂

So, lets come to the topic of this blog post. Over the last couple of weeks, I worked on devm functions and their incorrect usage. I couldn’t make it to update my blog properly regarding the same. But in this blog, I have tried to write good summary of my work on devm functions and by adding links wherever possible for someone who is more interested in the discussions and patches. First of all, lets start with introducing devm functions.

Devm Functions: What, Why and Where

There are some common memory resources used by drivers which are allocated using functions and stored as a linked list of arbitrarily sized memory areas called devres. Some of this memory is allocated in the probe function. But all of this memory should be freed on a failure patch or before the driver is detached. Else, the driver will leak resources and wastes main memory.

There are couple of reasons behind introducing devm functions. First is of course about resource leaking. It can be possible that if anything fails in the middle of probe function, it frees anything allocated. Also, remove function is just a duplicate code of probe’s error handling. And most important thing is it is hard to spot problems in failure handling with non-managed resource allocation. So, we need managed versions of such functions = devm functions. Devm functions basically allocates memory in a order resources are allocated and deallocates those memory automatically in a reverse order. Here, is a link of slides which can be useful to understand devm functions and their usages.

Problems I encountered or came across while looking in to devm functions

1. Basically sometimes what happens is developers want to use devm functions because they think that it is better to use managed resource functions but they don’t know how to use it and end up with messing things. For example, here is one of my patch. In this file, we already have devm_snd_soc_register_card and as I said devm functions automatically handles when to free memory. So, actually we don’t need to use function for unregistering the card. I have sent some patches for similar cases and I have provided links of accepted patches at the end of the blog.

2. While working on devm functions, I encountered that many files are using devm_free_irq in remove functions with the devm_request_irq in probe function. One can understand that we need devm_free_irq in remove function when we don’t have devm counterparts for each allocated resource function and it needs to occur before something else to be released. That can be a case where we need to call devm_free_irq explicitly. But not all cases are like that. Here is a link of one of such discussion on a case where use of devm_free_irq is not at all necessary. There are some other such interesting cases for devm_free_irq and but one need to look closely for each case. Also, it can be possible that there are some other such cases for other devm functions. One another example is this.

3. Sometimes it is possible that memory lives within a single function and frees after some line of code. Then we don’t really need devm functions because it just wastes extra memory used for devres structures and few extra cycles for maintaining them. Here, is such example.

Here, are those Coccinelle semantic patches which I used to detect such cases. File devm_entry_points is used to detect problematic usage of devm functions and devm_opportunity is used for finding files which are still using non-managed functions whose devm counterparts already exists.  I worked on each case encountered by devm_entry_points but not going to discuss it here. In case you have any questions please ask me here and I’ll be happy to answer them.

I sent many patches using both of these files and for some which came in to my way while working on devm functions. Here, is a links of some of my accepted patches for the reference and there are many more in their way to be accepted. All of my accepted patches can be found here.  I am going to send some more as still there are many opportunities where devm functions can be used.

I know understanding devm functions is little bit complicated at first but once you will understand them properly, you can enjoy the beauty of them. Please ping me for any queries regarding devm functions or my patches.

Links:

  1. power_supply: bq24735: Convert to using managed resources
  2. ASoC: tegra: Use devm_clk_get
  3. ASoC: tegra: Convert to managed resources
  4. ASoC: davinci-vcif: Use devm_snd_soc_register_component
  5. crypto: sahara – Use dmam_alloc_coherent
  6. ASoC: rockchip: i2s: Adjust devm usage
  7. ASoC: samsung: Remove redundant arndale_audio_remove
  8. ata: pata_arasam_cf: Use devm_clk_get

Update – 1: I have continued working on devm functions even after the internship. So, now there are many patches which are accepted in the mainline kernel. And still there are many opportunities where one can go for working on. So, here is a link of my all patches. One can go there and check the things for better understanding.

Creating virtual machine using KVM and virt-install/virt-manager

This post discusses about creating virtual machine using KVM, virt-install and virt-manager. So, here is a step by step process from installing necessary stuff to running your favourite os in virtual machine. I am assuming that you are running Ubuntu.

Step-1 :- Checking hardware virtualization

1. Check if your processor supports hardware virtualization or not.

egrep -c '(vmx|svm)' /proc/cpuinfo

If output of above command is 0 then your CPU doesn’t support hardware virtualization and if output is 1 or more then it does. But you still need to check in your BIOS id virtualization [VT-x in intel and AMD-v in AMD processor] is enabled or not.

2. You can also execute following command to check for kvm compatibility:

kvm-ok

Ouput of this command should be like following:

INFO: /dev/kvm exists
KVM acceleration can be used

If you see, something like following then you can still run virtual machines, but it’ll be much slower without kvm extensions.

INFO: Your CPU does not support KVM extensions
KVM acceleration can NOT be used

But if you see, something like following then check your kernel version. KVM works with Ubuntu-kernel only. So, if you are running vanilla kernel then there may be an issue. Either you need to download Ubuntu-kernel image or you can go for using kernel version which comes by default with particular Ubuntu version. For example, Ubuntu 14.04 comes with 3.13.0-24-generic.

INFO: /dev/kvm does not exist
HINT: sudo modprobe kvm_intel modprobe
FATAL: Module msr not found.

Step-2 :- Installation of kvm

1. sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

2. Add your username to the group libvirtd

sudo adduser `id -un` libvirtd

After running above command reboot in your system to add your username effectively in libvirtd group. I repeat do not just relogin into your system, please reboot.

Step-3 :- Verifying installation

You can verify your installation using following command:

virsh -c qemu:///system list

This should give output like this:

Id Name State
———————————-

If this command fails to connect with hypervisor, then you can check the errors and the solutions here.

Step-4 :- Restart kernel modules

modprobe -a kvm

Step-5 :- Install virt-viewer

You can install virt-viewer for viewing instances:

sudo apt-get install virt-viewer

Step-6 :- Install virt-manager

This is optional. Virt-manager is a GUI application for creating and managing virtual machines. You can install it either from Ubuntu software center or using following command:

sudo apt-get install virt-manager

Step-7 :- Creating virtual machine

You can either use following command for creating virtual machines or go for this link if you want to create it using virt-manager.

virt-install --name=guest_name --arch=x86_64 --vcpus=1 --cdrom=/var/lib/libvirt/image/ubuntu-12.04.5-desktop-amd64.iso --disk path=/mnt/virtual_machines/guest_name.img,size=20

Virt-install is written using Libvirt API. It is very interesting to learn how all things are binded together. In case someone is interested, then go for cloning repo or can browse online here. Also, in the command above I just gave values to options which are mandatory. One can check other options too.

So, this is complete process of creating virtual machine using KVM and libvirt. I will write some other posts about libvirt as I am learning it these days along with my internship.